home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000025_news@newsmaster….columbia.edu _Wed Oct 1 20:23:56 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA15160
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 1 Oct 1997 20:23:55 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA29285
for kermit.misc@watsun; Wed, 1 Oct 1997 20:23:55 -0400 (EDT)
Path: news.columbia.edu!panix!news.eecs.umich.edu!newsxfer3.itd.umich.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit via PPP under DOS?
Message-ID: <XrKuqa+e0PBq@cc.usu.edu>
Date: 1 Oct 97 17:38:37 MDT
References: <k1c7kBQEU5Wv@cc.usu.edu> <omafgv99sa.fsf@tees.cs.ualberta.ca>
Organization: Utah State University
Lines: 80
Xref: news.columbia.edu comp.protocols.kermit.misc:7790
In article <omafgv99sa.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
> In article <k1c7kBQEU5Wv@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>
>> Let's go through the PPP driver situation again when the driver
>> presents an Ethernet Packet Driver interface.
>> PPP is a point to point link involving only two stations: this
>> end and the other end. It is not a broadcast medium, and thus ARP does not
>> apply.
> pppd with the proxyarp option allows this. Here's what the pppd(8) man page
> says:
> Add an entry to this system's ARP [Address Resolution
> Protocol] table with the IP address of the peer and the
> Ethernet address of this system.
> Also, some terminal servers provide such proxy arp. At least the Cisco
> terminal server that runs at our uiniversity's login server. (Interestingly,
> it only does this when the user properly identified themselves to the server,
> otherwise it allows PPP, but does not give proxy arp.)
>
>> A PPP driver presenting an Ethernet interface is indistinguishable
>> from real Ethernet at the protocol stack level (i.e., by Kermit). That
>> driver must then FULLY simulate a broadcast medium of many stations, yet
>> they often fail completely to do that job.
>
> I'm not saying that the Kermit class 1 handling is worse than than of other
> WATTCP apps. I suspect that Kermit does some more checks or expects more from
> the ethernet driver than other WATTCP apps, in other words it uses the
> ethernet driver more properly than other WATTCP apps. But the fact remains
> that these apps can use emulated class 1 drivers, while Kermit can't.
> Sometimes worse is better.
This looks more and more like an argument waiting to happen, due to
lack of specific information. I thought I explained the difficulties with
a driver purporting to be Ethernet but isn't; they are fundamental. The
paragraph above is so loose that I am discarding it.
>> Half measures are failures too.
>
> Well, these half measures prove to be adequate for other WATTCP apps.
which are tailored for a point to point link, no doubt.
>> SLIP is a point to point link. It is not an Ethernet-style
>> interface. Kermit knows about SLIP and treats it as a point to point
>> comms pathway without MAC addresses. Use SLIP interfaces.
>
> What are the benefits of an ethernet interface to a SLIP interface:
> - there are apps that only support ethernet interfaces. Kermit couldn't
> coexist with such apps because it demands a SLIP interface.
Argumentative again. No, Kermit does not "demand" SLIP, but if the
alternatives fail to meet specs then that is hardly Kermit's fault.
> - Ethernet interfaces support BOOTP. Is BOOTP impossible with a SLIP
> interface?
> - How about DHCP?
Time to read up on these guys. Both use UDP over IP. How IP gets
put onto the wire is another matter. Please do keep in mind that both
BOOTP and DHCP are sensitive to physical address, something which SLIP
lacks.
> - RARP is obviously impossible with a SLIP interface, but then it doesn't even
> apply.
> - Is there anything else?
>
>> There is no such thing as a standardized PPP interface, alas, and thus
>> Kermit does not have code to deal with the many PPP interfaces out there.
>
> EtherPPP's documentation mentions class 15 (SLFP). Is that an example of a
> non-standardized PPP interface?
>
>> Avoid badly designed PPP drivers, please.
>
> Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
> designed driver too? How about Windows PPP drivers, do they support an
> Ethernet interface?
I think this ground was well covered in my long message on the
matter a couple of weeks ago.
Joe D.